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Secure orchestration is an important concern in the internet of service. Next to providing the required 
functionality the composite services must also provide a reasonable level of security in order to protect 
sensitive data. Thus, the orchestrator has a need to check whether the complex service is able to satisfy 
certain properties. Some properties are expressed with metrics for precise definition of requirements. Thus, 
the problem is to analyse the values of metrics for a complex business process. 

In this paper we extend our previous work on analysis of secure orchestration with quantifiable proper- 
ties. We show how to define, verify and enforce quantitative security requirements in one framework with 
other security properties. The proposed approach should help to select the most suitable service architecture 
and guarantee fulfilment of the declared security requirements. 

1 Introduction 

Orchestration of complex web services is a multidimensional problem. Various criteria must be considered 
when different alternatives exist. Typically, one of such criteria is security. Recently, the security issues of 
service composition are receiving major attention EUl l22l |4] |7J ED [91 . Among them, formal methods have 
been successfully applied for modelling and analysing several different aspects of service security. In practice, 
these techniques generate a formal abstraction of the services under analysis. Then, a verification procedure is 
applied to find a formal proof of compliance between the model and the security specifications. 

The first difficulty arises from service abstraction. Indeed, it is crucial that services are modelled in a "safe" 
way, i.e., without neglecting any security-relevant behaviour they can generate. The problem is that this feature 
is not always guaranteed as specification and implementation is often developed independently. 

Although several, effective algorithms for software verification exist, e.g., model checking iTTTTl . they often 
require some modification to be applied to web services. Indeed, the algorithms typically check the compliance 
between a specification and a model and, if the check fails, they return a description of the detected error, e.g., a 
behaviour of the model that violates the specification. However, web services are designed and developed sepa- 
rately and they commonly have different and independent security requirements. Moreover, they are oriented to 
the composition and they can produce many different models, i.e., one for each possible orchestration. Hence, 
the verification process cannot just focus on an illegal orchestration, but should help in finding valid ones. 

Service usages are often based on security metrics. Metrics conveniently use mathematical values to rep- 
resent some "qualities" of a service. Several authors, e.g., see |[23l[T8l . proposed mathematical models for the 
definition and composition of security metrics. 

In this paper we propose an extension of previous work (see Ifl2l [T3lD on secure service orchestration 
integrating facilities for composing and verifying security metrics. In particular, we start from the service 
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model proposed by Bartoletti et al. EJ. Roughly, they propose a type and effect system for producing safe 
abstractions of the behaviour of web services. Then, the authors verify these abstractions against the security 
policies, locally specified by each service, to find a valid composition. 

We extend their model by introducing metric checks and metric annotations on their abstractions. We use a 
mathematical structure, called c-semiring, in order to generalise our model and be independent from the metrics 
used for the analysis, but still be able to reason on these metrics. Metric annotations are obtained through a 
new, improved type and effect system. In this way, we generate metric-annotated abstractions which contain 
both security and metric requirements. All the requirements are applied to different portions of the service 
orchestration through a local scope. 

The main advantage of this approach is the possibility to model and compose both security and metric 
requirements in a single framework. Service developers apply security policies and metric checks to some 
parts of their services. Our type and effect system extracts history expressions from the implementation of the 
services. History expressions safely denote the behaviour of service invocations. Within a history expression, 
the type and effect system adds extra annotations for metrics, metric checks and security framings. Then, we 
adopt the same verification procedure described in |4l with special pre-processing steps for assigning correct 
metric labels to each service. The final result is a complete framework for defining, modelling, verifying, and 
enforcing both security and metric requirements in order to find valid service orchestrations. 

This paper is structured as follows. Section [2] introduces the working example we will develop during 
our presentation. In Section [5] we describe our extension of the programming language X req and we define its 
operational semantics. Then, Section |4]presents our type and effect system and Section[5]describes the analysis 
of security and metric requirements. Finally, Section [7] concludes the paper. 



2 Running example 

The travel agency BestTravel offers a travel planning service to its customers. BestTravel exploits existing 
services for implementing the complex task of (?) booking a connection (consisting of one or more flights) to 
the destination, (ii) booking a hotel room, (in) paying the acquired items (i.e., flights and hotel room), and 
(iv) providing the customer with a signed receipt. As usual in service-oriented architectures, the four subtask 
described above are provided by existing web services. 

The service developer starts from an abstract workflow describing the behaviour of BestTravel and produces 
a corresponding implementation. The abstract workflow depicts the atomic operations that the service must 
implement and how they compose each other. In the case of BestTravel, most of the atomic operations are 
invocations to other services. Figure [T] shows the abstract workflow of BestTravel. 
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Figure 1: Abstract workflow for BestTravel. 



Reading Figure [T] (from left to right), we can understand the service behaviour. In words, a session of 
BestTravel works as follows. The service runs two procedures in parallel (rooted in v). The first one (upper 
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where fv is the standard function returning the set of free vari- 
ables of an expression e. 



Table 1: Syntax of X req a.nd abbreviations 



path of the workflow) is responsible for booking a flight connection for the travel destination. In practice, 
BestTravel invokes a service looking for a direct flight, i.e., search direct flight. Then the execution can take 
two alternative branches (<$> node): it can invoke a payment service for booking the flight, i.e., book flight, or it 
can start a new research for a multiple-flight connection, namely an itinerary, and book it, i.e., search itinerary 
and book itinerary. Concurrently, the second process (lower path) invokes services for searching and booking 
a hotel, i.e., search hotel and book hotel. When the two parallel procedures terminate, BestTravel iteratively 
invokes a digital signature service, i.e., sign line, for applying integrity and authenticity tokens to the hotel 
receipt and terminates. 

A requirement of BestTravel is to have risk level of the performed tasks (in particular, flight booking, hotel 
reservation and receipt signature) less than 75. Therefore, two problems must be solved: (i) statically estimate 
risk for the composition plans; (2) in case some execution path in the composition plan fails the requirement, 
dynamically check the risk of selected paths and prevent the failure of the requirement if a risky path is selected. 



3 Service structure 

In this section we present an extended version of A -calculus, called X req 0. First, we extend our previous work 
with two main novelties: parallel composition and metric facilities . Parallel agents in this work are defined 
without modifying the original syntax of the calculus. We obtain it by re-defining the operational semantics 
of X req . Second, we incorporate metrics into our formalism using special operations for denoting metric anno- 
tations and metric constraints. These operators are interpreted in a c-semiring mathematical structure. Metric 
facilities allow us to model metrics which are used in service composition. 



3.1 Syntax 

First, we define the syntax of expressions e,e' as shown in Table [I] Briefly, * is the closed, side effects- 
free expression, r, r' £ denotes system resources and x,y are variables. Access events a(e),fi(e') represent 
the access to a certain resource, resulting from the evaluation of the event argument, through a specific op- 
eration/channel (e.g., a and /3). Conditional term if Athene else e' represents a branch between two 
expressions (where b is a boolean guard). A function is defined through the term X z x.e, where e is the function 
body in which x is the formal parameter and z denotes the function itself (for recursive invocations). Instead, the 
term ee' denotes the application of a function e to a parameter e' . We feel free to use parenthesis for grouping 
either a function or its argument in order to improve readability. Security framing is used to apply the scope of 
a security policy cp to a term. We also use metric framing for expressing a term laying in the scope of a metric 
constraint y. Finally, a service request req p z — > z' denotes the invocation of a service having a certain func- 
tional interface, i.e., z — > %' shows that the function requires a type z as input and produces type z' as output, 
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Ax.(search_f light _f or (x); 
if is_available 

then reserve(FLIGHT_No);FLIGHT_No 
else N0_FLIGHT) 

Ax.(search_f light _f or (x); 
if is_available 

then reserve(FLIGHTJJo);FLIGHTJJo 
else if can_overbook 

then overbook(FLIGHT_No);FLIGHT_No 
else NO _FLIGHT) 

Ax. (gener at e_travel_to(x); reserve (ITINERARY); 
insurance(lTINERARY); ITINERARY) 

Ax. (gener at e_travel_to(x); reserve (ITINERARY); 
ITINERARY) 



9 
10 



Ax. (f indJiot el_3s (x) ; book(HOTEL) ; 
HOTEL _RESV) 

Ax. (if high_season 

then f ind_hotel_2s(x) else f indJiotel_4s(x) 
book(HOTEL) ; HOTEL _RESV) 

Ax.((if registered_user 

then * else var_charge(x));buy(x);RCPT) 

Ax. ( c onst .charge (x) ; buy (x) ; RCPT) 

Ax.sign_64(x); SIGNED _D0C 

Ax.sign_128(x);SIGNED_D0C 



Figure 2: Implementation of the services of Example [TJ 



and is labelled with a unique identifier p. Although, it is hard to create the X req representation for non experts 
such the model may be created automatically, similar to transformation of Java code 0. 

For the sake of presentation, we introduce some useful abbreviations (see Table [TJ. Moreover, to improve 
the readability we feel free to use simple expressions for conditional guards, e.g., is.available or is_empty, 
which have a straightforward interpretation in the context we use them. We also use upper cases for resources, 
e.g., HOTEL and FLIGHT, and lower cases for actions, e.g., book(. . .) and buy(. . .). 

According to the standard X req theory, we define security policies through usage automata Usage 
automata resemble non deterministic finite state automata (NFA) defined over the alphabet of access events. 
A sequence of actions is compliant with a certain policy if its corresponding usage automata does not reach a 
final, offending state reading the trace, i.e., valid traces are those rejected by the automata (see [2] for details). 

Our main focus in this section is on the definition of metric constraints. Indeed, we introduce a syntax for 
defining metric checks which then we apply through metric framing. In particular a metric check has the form 
J=T >t d where T is a metric name, >j is its order relation and d is an element of T. Here we slightly abuse 
our notation for the sake of simplicity, in order to show that the metric computed for a business process must 
be better than some predefined value (i.e., threshold). In practice, a metric check is satisfied by a value d' if 
d' >j d. If so we write d' G y. 

Example 1. We continue our running example. We assume the (sets of) resources: £ = {ITINERARY}, J^" = 
{FLIGHT _No, NCLFLIGHT}, = {HOTEL _RESV}, SB = J^U J^U^ and 9 = {RCPT, SIGNED.D0C}. In Figure|2] 
we propose the X req implementation of the services informally introduced in Section|2] 

Intuitively, service 1 receives an input airport x and searches a direct flight (action search_f light_f or). 
Then, depending on the is.available boolean flag, the service either reserves a seat (reserve) and re- 
turns the flight number FLIGHT_No, or returns the N0_FLIGHT value. Service 2 works similarly. The main 
difference is that, if the flight is not available, it checks whether it is possible to make an overbooking reser- 
vation (can.overbook flag) and proceeds with the reservation (overbook) before returning the flight number 
or the N0_FLIGHT value. Instead, service 3 finds a sequence of flights for the destination, namely an itinerary 
(generate_travel_to). Then the itinerary is reserved (reserve), a travel insurance is stipulated (insurance) 
and the itinerary is returned. Service 4 resembles 3, but no insurance is activated. Hotel booking services, i.e., 
services 5 and 6, receive a destination city x and book an hotel (action book) before returning the hotel reser- 
vation H0TEL_RESV. The main difference between the two services is that service 5 looks for a 3 stars hotel 
(action f ind_hotel_3s) while service 6, after discriminating on the flag high_season, searches either a 2 
stars or a 4 stars hotel (actions f indJiotel_2s and f indJiotel_4s, respectively). Payment services 7 and 8 
receive an item identifier x and return an electronic receipt RCPT after performing a purchase operation (action 
buy). However, while 8 charges the operation with a constant, extra amount (action const _charge), service 
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1 Xx.{y{X z y. 

2 : : if is.empty then SIGNED_DOC else (req p , @ -» &)y,zy ) 

3 : fork y((A/. (req p , SS -> ^)/)((req p3 ^ -> jr)CITY)) 

4 : and y<A/'. (if no_direct_f light then (req p4 SS -> ^)((req pj ,e/ J^) AIRPORT) 

5 : : else (req p6 ^ -> ^)/')((req p7 stf .9) AIRPORT) ) ) 



Figure 3: Implementation of BestTravel. 



7 applies either no commission charge or a variable amount (action var_charge). Finally, signing services 
accept a document x and return a signed version of it SIGNED _D0C. The only difference between them is that 9 
uses a 64 bit key for the signing process (action sign_64) while 10 uses a 128 bit ones (sign_128). 

Note, that with several alternative services which provide the same functionality we have several different 
possible execution paths which have different security properties. □ 

Example 2. We assume the existence of the resources: stf = {AIRPORT} and ^ = {CITY}. In Figure [3] we 
propose a X req implementation of the workflow of the BestTravel service, called eg. 

In words, eg carries out three tasks: it concurrently runs (i) a hotel booking process (line 4) and (ii) a 
flight booking one (lines 5-6) and, then, (Hi) executes a signature procedure (line 2). The first process consists 
of an invocation to a hotel search service using the resource CITY. The result is then passed as input for (an 
invocation to) a payment service. Similarly, the second process requests a itinerary searching service using the 
resource AIRPORT. Then, according the evaluation of the guard no.direct .flight, the service either starts a 
new request to flight searching service and proceeds with the payment or just invokes a payment service. The 
final result of this concurrent execution is the document returned by the first process. This value is then used as 
the actual parameter of the last operation of the service. It consists of a recursive function which, depending on 
the guard is_empty, can either return the resource SIGNED _D0C or invoke a signing service and loop. 

All the three tasks are subject to a metric requirement y = Risk < 75, i.e., each of them must be executed 
under a risk factor lower than 75 ($). □ 



3.2 C-Semirings 

Our framework exploits the notion of c-semiring for the abstraction of metrics and operators over metrics [6]. 
Usage of this mathematical structure allow us to provide a generic framework for all metrics which could be 
considered as c-semirings. A c-semiring consists of a set of values D (e.g., natural or real numbers), and two 
types of operators: multiplication ((g)) and summation (©) of values and constraints. Formally, a c-semiring is 
defined as follows (see the work of S. Bistarelli et. al., for more details j6l). 

Definition 1. A c-semiring T is a tuple (D,ffi,®,0,i) where 

• D is a (possibly infinite) set of elements and 0, 1 ED; 

• ffi, being an addition defined over D, is a binary, commutative (i.e., d\,d2 G D =^ d\ @d2 =d2@d\) and 
associative (i.e., d\,d2,d^ G D d\ ® (d2®d?) = (di ©c/2) ©^3) operator such that is its unit element 
(i.e., d\ GD=^ [d\@0 = d\ =0@d{); 

• ®, being a multiplication over D, is a binary, commutative and associative operator such that 1 is its unit 
element and is its absorbing element (i.e., d\ G D =^> d\ © = = © di); 

• <g) is distributive over additive operator (d\ © (^©^3)) = (di ©^2) © (d\ ©c?3); 

In this work we focus on a special subset of c-semirings: 

Definition 2. c* -semiring is a c-semiring with © satisfying the following condition: Vfi?i,c?2 G D d\ @da = 
d\ or d\@d2= d2 
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{r\,d,e)^ n {r\',d',e') F(a,r)=d' 

(S-Evi) (S-Ev 2 ) 

(T],d,a(e)) ->■„ {r\' ,d' ,a{e>)) {r\,d,a{r)) -> n {j]a(r),d®d' ',*) 

: T ^> t' e Srv n{p)=l (r},d,ei_) (r}' ,d' ,e\) 

(S-Req) — - (S-Ap Pl ) 



(Tj,rf,(req p t')v) (r},d,e e v) (r},d,e 1 e 2 ) {r\' ,d' ,e\e 2 ) 
(r},d,ez) ->?t W ,d' ,e' 2 ) 

(S-App 2 ) (S-App 3 ) (ri,d, (X z x.e)v) (r],d,e{v/x,X z x.e/z}) 

{r\,d,e\_e 2 ) ->•* (r]',d',ei^ 2 ) 

(T],d,e)^ K {T]',d',e') ?]' |=9 rj|=<p 

(S-Seci) (S-Sec 2 ) 

{T},d,q>[e\) -+„ (ri',d',(p[e'}) p[v]) v) 

(r],d,e) ->„ {r]',d',e') d'ey d ^7 
(S-Meti) (S-Met 2 ' 



(r},d,y{e))^ n {r}',d',Y{e')) ' (T],d,y{v)) -+ n {i],d,v) 

(S— If ) (tj,^, if b then e„ else eg) (lJ,rf,CB(fc)) 

Table 2: Operational semantics of X req 

Definition 3. <t is a total order over the set D, such that <fi <r iff ^1 ©<^2 = d%. 

In this work we need a reverse operation for summation which is defined as follows. 
Definition 4. d\ di = d\ iff d\®d2 = fi?2- 

In words, this operation always returns the worst possible value. 
Property 1. Operation is associative, commutative, idempotent, distributive over (g), and monotone^ 

Example 3. Regarding to the security targets BestTravel is going to use two metrics: trust and risk. Trust is 
often computed as a probability that the requested service is going to behave as agreed. Thus, trust could be 
seen as a value between and 1, which is aggregated by multiplying and the higher value is considered better 
than a lower one. C*-semiring for trust value formally is defined as follows: ([0, 1], max, x ,0, 1). This type of 
c-semirings is known as possibilistic semiring. 

Risk, considered as possible losses, has the domain of positive real numbers. Multiplication of risks is 
summation of possible losses, when the lower value is, naturally, considered more preferable than the higher 
one. Therefore, c*-semiring for risk could be seen as (Af + U {00}, min, +,°°,0), known as tropical semiring. □ 

3.3 Operational Semantics 

Service execution is driven by the operational semantics defined in Table [2j Intuitively, a computation step 
consists of a reduction from a source configuration to a target one. Configurations are tuples {r],d,e) where 
T] is an execution trace, i.e., the sequence of events performed so far (e denotes the empty execution trace); 
d is the current metric value; and e is a X req term, which describes the part of the service under evaluation. 
The operational semantics is driven by a composition plan % which is responsible for providing a mapping 
between each service request and an actual service, in symbols %{p) = £ where p and I are request and service 
identifiers, respectively. In the following we also use — ►* for the transitive closure of — > K . 

Below, we provide an informal explanation of the operational semantics rules. To be performed, an action 
a requires its argument e to be evaluated first (rule (S— Evi)). If the action target reduces to a resource r, the ac- 
tion takes place and the current history rj is extended with the corresponding event a(r) (rule (S— Ev 2 )). Also, 
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Table 3: Definition of function Fy&&. 



the current metric is updated with the metric value for the event 05 (r). F is a metric and context-dependent pre- 
defined function which assigns a metric value to every event. In practice, function F can be found analytically 
(e.g., risk=probability x impact), derived form past experience, i.e., using monitoring or assigned by experts 
(e.g., number of successful virus attacks). A conditional expression is reduced to one of its branches (i.e., e tt 
and e^J) depending on the value of its guard b (rule (S— If )). Here we assume an evaluation function B, assign- 
ing to each possible guard a boolean value, is to be defined. Rules (S— Appi), (S— App2) and (S— Apps) define 
the behaviour of function application. Briefly, a function e and its argument e' are both reduced to values, i.e., 
terms that admit no further reduction. The steps of the two reductions are executed in a non deterministic way, 
without any fixed priority between the choice of (S— Appi) and (S— App2). When both computations generate a 
value, i.e., a lambda abstraction and its argument, the application reduces to the body of the function where the 
formal parameter x is replaced by the actual value v and the variable z is substituted with the function itself (rule 
(S— App 3 )). Note that, along the paper, we use v,v' to denote values, i.e., closed, effect-free terms being either 
*, resources, A -abstractions or service requests. Rules (S— Seci) and (S— Sec 2 ) define the behaviour of the 
security framing. Basically, a security framing behaves as its target unless it tries to extend the current history 
Tj to an illegal trace. When the target expression reduces to a value, the policy framing can be removed, i.e., 
the corresponding security check is deactivated, if the current history is a legal one. Similarly, (S— Meti) and 
(S— Met2) rule metric checks. In words, a metric check forces metric values generated during the execution of 
a term e to comply with a constraint y. Finally, service requests (rule (S— Req)) works by running the service ei 
with actual parameter v. Among all the compatible services, i.e., those having the same behavioural interface 
specified by the request p, appearing in the service repository Sr^ one is selected according to the current 
composition plan Tt. Note that the interface of actual services is also annotated with a history expression H 
which represent the service contract (see Section [4] for more details on this point). 

Example 4. Let e\ be the implementation of service 1 proposed in Example[T] We assume B(is_available) = 
tt, and consider the semiring Risk introduced in Example [3] and the function Fr\ s ^ which returns the values 
shown in Table [3] (where missing entry evaluate to and • stands for any compatible value). Then, we have the 
following computation for * = (£,0, (<?i)AIRP0RT) (where AIRPORT is a resource in sf). 



search_flight_for(AIRPORT); 
if is_available 
£,0, then reserve(FLIGHT_No); 
FLIGHTJJo 
else NCLFLIGHT 



if is_available 

then 

search_f light _f or (AIRPORT), 0, reserve (FLIGHT_No) 

FLIGHTJJo 

else NCLFLIGHT 



>,r ( search_flight_f or (AIRPORT) , 0, 



reserve(FLIGHTJJo) 
FLIGHTJJo 



search_flight_for(AIRPORT) 
reserve(FLIGHTJJo) 



15, FLIGHTJJo 



2 Where tt ffii&ff stand for "true" and "false", respectively. 

3 Here we assume a service repository to be always available at runtime. In short, a repository is a finite set of tuples, each of them 
containing at least the service interface and being uniquely identified by the service location t. 
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H,H' ::= e \ h \ a(r) \ H ■ H' \ H + H' \ H \ H' \ d#H \ <p[H] \ y{H) \ jih.H 

Table 4: Syntax of history expressions 



In words, the computation proceeds as follows. The first step consists in applying the rule (S— App 3 ) which, 
in practice, replaces all the occurrences of x with AIRPORT. The second reduction collapses two rules, i.e., 
(S-Ev 2 ) and (S-App 3 ). As a result of the rule (S-Ev 2 ) a new event, that is search_f light_f or(AIRPORT), 
is added to the execution trace e. Also, according to the given definition of fRj S k, the current metric is updated. 
Recalling the c* -semiring specified in Example [3] we note that the multiplication operation over risk values 
is the sum, then 000 = + = 0. The subsequent step evaluates the conditional guard is_available and 
chooses the "then" branch (rule (S— If )). Finally, the last piece of computation repeats the operations described 
above and updates the current configuration by both adding a new event to the execution history and changing 
the current metric value (i.e., 0(g> 15 = + 15 = 15). Since the term appearing in the last configuration is a 
value, i.e., the resource FLIGHT _No, the computation terminates. □ 



4 Type and effect system 

In this section we present our proposal for a type and effect system. It derives from the type and effect system 
presented in [4] from which it inherits most of its rules. 

4.1 History expressions 

Briefly, a type and effect system carries out the extraction of behavioural description from a certain expression 
while typing it. We use history expressions for representing the behaviour of a program in terms of the execution 
histories it can generate at runtime. 

The main novelties introduced by our type and effect system are (i) parallel composition and (ii) metric 
annotation. Parallel composition denotes two elements which can run concurrently, in an interleaving fashion. 
Instead, metric annotation associate a metric value to a certain behaviour. Table [4] reports the syntax of history 
expressions. 

A history expression can be the empty one e, a variable h or an access event ct(r). Valid history expressions 
are also concatenations (H -H'), unions (H + H'), parallel compositions (H \ H'), metric-annotated expressions 
(d#H), security framings (cp[H]), metric checks (j{H)) and least fix-point, recursive expressions {jih.H). 

A history expression denotes a set of execution traces. We use a denotational semantics to bind each history 
expression to the corresponding set of traces. The semantic function [-J. is defined in Table|5] Note that we use 
the environment 8 for mapping variables to set of traces. 

A e expression denotes the singleton containing the empty trace (we use e for both void history expressions 
and empty traces as they are clearly identified by the context). The semantics of a variable h corresponds to the 
set of histories associated to it in 8. A history expression a(r) denotes the singleton {a(r)}. The semantics of a 
sequence H H' is the set of traces T]T]' such that v\ G lH}§ and tj' € p/'flg. Similarly, the semantics of a choice 
is the union between the sets denoted by the two sub-expressions. Parallel history expressions H | H' denote 
the set of all the possible interleaving of traces belonging to the two sub-expressions. Interleaving semantics 
is defined through the binary operator Q. Intuitively, if one of the two considered histories is e, the operator 
Q returns the other one. Instead, for non-empty traces it generates all the possible sequences representing 
concurrent executions. This process is obtained by considering all the possible prefixes of one trace, adding 
the first action of the other trace and recursively applying the ( ) operator to the remaining "tails". In the style 
of 0, security framing denotes execution histories wrapped between two special actions [,p and ]«, (for brevity, 
we write (p[X] in place of {(p-X-]^). These special actions mark the activation and deactivation points of a policy. 
Following a similar reasoning, the semantics of y(H) is the set of traces denoted by H wrapped by the special 
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i 1 

[ej, = {£} Mr)} s = {a(r)} {H-H'js = MsWls lH+H>} 8 = Ms^Wh 

l(p{H}} 5 = <p[lHj s ] {d#Hj 8 = Ms [Y(H)h = YiMs) Ms = 5(h) 
[H | H'js = |J (fy lnh.H} 5 =\Jf n (e) where/(X) = {Hj §{m 

where the binary function Q is recursively defined as follows. 

I I 

Table 5: Denotational semantics 

actions (y and ) y (with the obvious meaning). Finally, iih.H denotes a fix point operation over the set of traces 
denoted by H (see |5] for further detail). 

Moreover, we introduce a partial order relation C between history expressions such that H QH' 44> V5 . \H ] § C 

[His- 

4.2 Typing relation 

In the following we introduce our typing rules. The main difference with respect to the rules proposed in 
previous works is that here we generate metric annotated history expressions during the typing process. Before 
presenting the typing rules, we need to introduce types and type environments. 

Definition 5. (Types and type environments) 

i 1 

x,x'::=unU \& \ x ^ x' r,V ::=0 | T;x : % 

i i 

A type can be both a simple type, i.e., unit or the resource domain or a function from type T to type 
Functional types also carry a history expression H which represents the latent effect of invoking the function. 
Then, a type environment Y, being either the empty one or the one obtained through a new binding T,x .x, is 
a mapping from variables to types. 

The typing relation has the form F,H h e : z. It must be read as "under the environment T and carrying the 
effect H, expression e has type t". The rules in Table [6]denne the typing relation. 

Briefly, the expression * has unit type and generates no side effects (H = e, rule (T— Unit)) while a resource 
r, being also side effect free, has type £& (rule (T— Res)). The type of a variable x depends on the typing context 
provided by T (rule (T— Var)). Abstractions (rule (T— Abs)) has an empty effect and produce a functional 

type t — > x' from their input to their output types. The latent effect H is the one obtained from typing the 
function body. Rule (T— Ev) requires more attention. Indeed, we say that an expression a(e), having type unit, 
generates a history expression which is the sequence between the history expression deriving from typing its 
argument e and the summation (i.e., a finite sequence of choice operators) of all the possible access actions a 
to a compatible resource re£ Also, all of these access events are annotated with the metric value provided 
by the function F. The application of a function e to an argument e', i.e., rule (T— App), has type equal to the 
return type of e and a history effect which is the sequence between (1) the two effects of e and e' in parallel and 
(2) the latent effect of the function. Security and metric framing (rules (T— Frm) and (T— Met)) have the same 



4 For simplicity here we assume a single set 3$, but, in general, we assume to have a finite number of resource domains M\ 
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Y;x : x;z : X —¥ x' H h e : X 1 

(T-Unit) T,e h * : unit (T-Res) T,£ h r : 8t (T-Var) T, e h x : T(x) (T-Abs) ^ — 

r, £ h X,x.e : T — > t' 

r,H\-e:M r,H\-e:t^r' r,/f'h/:l r,ffhe:t 

(T-Ev) (T-App) (T-Frm) 

T,H- £ (F(a,r)#a(r))\-a(e):unit T, (H \ H') ■ H" \- ee' : x' T,(p[H] h <p [e] : T 

re,* 

r,flhe:T r,flhe:l I\# h e' : X T,H\-e:x HHH' 

(T-Met) (T-If ) (T-Wkn) 



r,y(H}\- y(e) :x r,/f h if g' then e else e' : T T,//' h e : T 

(T-Req) 



/ = {// | e t : x ^ x 1 e Srv} 



r,£hreq p T^T':l^>T' 



Table 6: Typing relation 

type as their targets and produce wrapped history expressions. Rule (T— Wkn) says that we can always type an 
expression under a more general history expression. Finally, rule (T— Req) says that a service request has the 
same type of its signature but for its latent effect which is obtained as the disjunction of all the (latent effects of 
the) possible servers appearing in the repository Srv. 

Example 5. Consider service 9, we call its implementation eg, of Example [p Writing it without abbreviations 
we obtain: eg = A z x.(A„/y.SIGNED_D0C)sign_64(x). Then consider the function Fmsk of Table[3] We type eg as 
follows. 

r', e h SIGNED _D0C : 9 T(x) = 9 

T, £ h ASSIGNED _D0C :TAf T,H 9 h sign_64(x) : unit 
T,H 9 h (^.SIGNED _D0C)sign_64(jc) : 9 



where H 9 = l#sign_64(RCPT) + l#sign_64(SIGNED_D0C), r = x : &;z : 9 % Si and V = F;y : V, w : T A 9. 
Following a similar reasoning we type all the services of example [T] as shown in Figure [4j For brevity, in the 
following we use Hi to denote the latent effect of service e,. □ 

Example 6. Using the notation introduced in the previous examples for denoting the history expressions of 
services, we type the BestTravel implementation eg as in Figure [5] We call Hb the latent effect labelling the 
arrow type of □ 

The main result on the type and effect system is type safety. In words, type safety guarantees that effects 
produced by the type and effect system safely denote the behaviour of services. 
Theorem 1. IfF,H h e : % and (e,d,e) — >* n (r\,d' ,v) then V5.T] G \H\ S . 

Interestingly, the extensions presented in this paper do not invalidate this result originally proved by Bar- 
toletti et. al. [4]. In the next section, we show that history expressions safety is also preserved under metric 
factorization. 



5 Security and metric analysis 
5.1 History expressions and semirings 

Metric annotations are used to label a history expression with metric values which are expected to be produced 
dynamically. However, metric annotations are locally associated with parts of a history expression while, in 
general, it would be preferable to have a single value labelling the whole expression. In particular, we are 
interested in a procedure which turns a history expression into a corresponding normal form. 



42 



Metric-Aware Secure Service Orchestration 



e\ 


si 


ei 


si 


?3 


si 


e\ 


si 






<*6 
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0#search_f light _f or (AIRPORT) • 
15#reserve(FLIGHTJJo) + \ / 20#overbook(FLIGHT_No)+ 
0#reserve(NO_FLIGHT) ) + \ 0#overbook(NO_FLIGHT) + £ 



(0#search_flight_for(AIRPORT))-(15#reserve(FLIGHT_No)+0#reserve(NO_FLIGHT)) 

> & 

(0#generate_travel_to(AIRPORT))-(15#reserve(lTINERARY))-(10#insurance(lTINERARY)) 



(0#generate_travel_to(AIRPORT))-(15#reserve(ITINERARY)) 



(20#find_hotel_3s(CITY))-(20#book(H0TEL)) 



(30#f indJiotel_2s(CITY) + 15#findJiotel_4s(CITY))-(20#book(H0TEL)) 



I ( 8#var_charge(lTINERARY)+ \ 
8#var_charge(FLIGHT_No)+ 
8#var_charge(N0_FLIGHT)+ 
\\ 8#var .charge (HOTEL_RESV) J 



( 20#buy(lTINERARY)+ \ 
10#buy(FLIGHT_No) + 
0#buy(NO_FLIGHT)+ 
\ 10#buy(HOTEL_RESV) J J 



( 5#const_charge(ITINERARY)+ \ 
5#const_charge(FLIGHT_No) + 
5#const_charge(NO_FLIGHT) + 
\ 5#const_charge(H0TEL_RESV) J 



( 20#buy(ITINERARY)+ \ 
10#buy(FLIGHT_No) + 
0#buy(NO_FLIGHT)+ 
\ 10#buy(H0TEL_RESV) J 



l#sign_64(RCPT) + l#sign_64(SIGMED_D0C)^ 
0#sign_128(RCPT)+0#sign_128(SIGNEDJ30C) 



Figure 4: Types inferred from the services of Example [TJ 



es '■ unit 



r( {Hi +h 2 ) 



+ 

((H 3 +H 4 )-(H 7 +H & )) 




■Y{nh.({H 9 +H m )-h+e)} 



Figure 5: Type of BestTravel. 



Definition 6. A history expression H is said to be in metric normal form (MNF), iff H = d#H' and H' contains 
no metric annotations. 

In Table [7] we propose a set of equivalences that we use to move and compose metric annotations appearing 
in history expressions. The rules in Table [7] define the correspondence between the history expressions and the 
semiring operators. In particular, we can always add a multiplication-neutral annotation to a history expression, 
nested annotations are commutative and can be reduced to a semiring multiplication and choice correspond to 
the inverse of a semiring addition, namely a subtraction. Also parallel composition can be annotated with the 
(result of the) multiplication between the two subexpressions annotations. A security framing is orthogonal to 
metric annotation, i.e., they do not affect each other. Instead, metric checks have a precise effect on annotations. 
As a matter of fact, we can remove a metric check by forcing its target to be annotated with the difference 
between the inner annotation and the threshold of y. Finally, a recursion is annotated with the least fix point of 
the function <I> that extracts the metric annotation from the inner history expression after annotating the bounded 
variable h. 

A crucial property we want to prove on the equation rules of Table [7] is that they do not invalidate the 
semantics of history expressions. Such property guarantees that history expression transformations do not 
affect the safety property stated by theorem [T] 

Property 2. For all history expressions H and H'ifH = H' then V5.p?Js = {H'j s 
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H = l#H di#d 2 #H = d 2 #d Y #H = d x <g> d 2 #H d { #H x ■ d 2 #H 2 = d Y <g> d 2 #(#i ■ #2) 

di#H x +d 2 #H 2 = d\ ©~ ! d 2 #(#l +H 2 ) di#H\ \ d 2 #H 2 = d Y ®d 2 #{Hi \ H 2 ) (p[d#H\ = d#<p[H] 
y(d#H) = d#y{H) where y=T> T d' and d = d®~ 1 d' 

( H[ d#h / h ) = d'W 

\ih.H = d#ixh.H' where d = _1 4>"(0) and = < A 

( <i'#//' is in MNF 

1 1 

Table 7: Equational rules. 

Example 7. Having in mind that ©~ ! is max for Risk , consider the history expression H 2 of Example [5] 

H 2 = (0#search_f light J or(AIRPORT)) • (0#reserve(FLIGHT_No) + 15#reserve(N0_FLIGHT)) 

H 2 = ® (0 15)#(search_f light _f or(AIRPORT) • (reserve(FLIGHT_No) + reserve(NO_FLIGHT))) 

Note, that the right side of the previous equivalence is in MNF. According to the operations of the semiring 
Risk , the resulting annotation value is 15. □ 

Example 8. We write the MNF of the history expressions of Example [5] For brevity, we write Hj = di#H[ to 
emphasise the metric annotation of the MNF without showing the structure of H\. 

Hi = 20ttH[ H 2 = \Sm' 2 H 3 = 25#H^ H 4 = 15#H^ H 5 =40#H' 5 
H 6 = 50#% H-i = 2MHI, # 8 = 25#//^ H 9 = \#H' 9 H w = 0#H' W 

□ 

Intuitively, Example [8] shows that every history expression appearing in our working example has an equiv- 
alent MNF. In general, we know that all the history expressions can be reduced to a corresponding MNF as 
stated by the following property. 

Property 3. For each history expression H there exists H' such that H = H' and H' is in MNF. 

The last property we show is metric safety, which characterizes the most important quality of the metric 
annotations we generate. 

Theorem 2. IfT,H\~e:T and H = d#H' such that d#H' is in MNF, then for each execution (rj,d,e) — >* n 
(r\',d',e') holds that d' < T d®d. 

Similarly to type safety, this theorem guarantees that metric annotations produced by our equational theory 
provide an upper bound to the metric values generated by the execution of a term. As each of them has a 
corresponding MNF, this theorem can be universally applied to any history expression. 

5.2 Discussion 

During the presentation we have shown how our formalism can be applied to the modelling of complex business 
processes. In this part of the article we describe how the proposed theory can be applied to the verification and 
analysis of the security properties of web services. 

Basically, our proposal offers facilities that can be applied to all the stages of service design, implementation 
and execution. Statically, service designers can write their policies on execution histories and security metrics. 
Then, developers apply the scope of the policies to the service implementation. Finally, each service runs with 
proper checks controlling that the execution complies with the specification. 

These steps suffice to carry out the analysis of possible configurations of a complex abstract business pro- 
cess. The goal is to check whether the possible configurations satisfy desired policies. This information is 
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required in order to decide if we can avoid run-time controls. Naturally, if a configuration satisfies a policy or 
the worst possible metric value is better than a threshold, there is no need for an additional control. 

Note, that we assume that the declared policies/metrics for a specific service are genuine and the services 
are typed by a trusted type and effect system (implementation). Although this assumption is not true in general, 
here we focussed on the considered problem, i.e., aggregation of metrics and check of composite properties. 

In order to check that a certain business process satisfies properties or has sufficiently good metric value 
the analyst starts for a X req implementation of an abstract workflow, as it is shown in Example [2] Then, we 
assume the service repository and c*-semirings for considered metrics to be defined similar to Examples [T] 
and [3] The next step is to type the service implementation similar to Example [5] and [6j Finally, we aggregate 
metrics annotations, as it is done in Example [7] During this process, several analysis on the validity of history 
expressions can be carried out in order to prevent illegal service compositions. For a description of these 
techniques we refer the interested reader to Rl [12ll . 

Example 9. We use the history expressions in MNF shown in Example[8]to compute the MNF of Hg. Consid- 
ering the history expression appearing in Figure [5] we can replace every instance of Hi with the corresponding 
MNF di#H'j. Then we obtain the following equivalences. 

H B = (Y(H F )\y(H H ))-Y(H s ) 

Hp = (j20#H[ + 15##2) • ({28#Hj + 25#H' 8 ) + ((25#Hj + 15#H' A ) • (28#flJ + 25#Hg)))) 

H H = ((40##5 + 50#H' 6 ) • (28##7 + 25##g)) H s = lxh.((l#Hg + 0#H' m ) -h + e) 
Applying the rules of Table [7J we can reduce to the following history expression. 

H B = (y(73#H> F ) | y{lMH' H )) ■ y<°°#^> 
Recalling that y = Risk < 75 we conclude with the equivalences below. 

(y(13#H' F ) I y{lMH' H )) ■ y(oo#H' s ) = (73# Y (H' F ) 1 15#y{H' H ))-15#y{H' s ) = 223#((y(H' F ) | y(H' H )) ■ y(H>)) 

Interestingly, we note that, among the three instances of y, only the first one applies to a history expression 
satisfying the restriction, i.e., 73 G y. We cannot say the same for the other two instances. However, our 
semantics for metric framing forces the execution of all the parts of the service to respect risk constraints. In 
this way, even though some parts of the service are labelled with <», the overall risk is a finite value, i.e., 223. 

Since the last two instances fail the restriction the dynamic analysis is required. Note, that the hotel reser- 
vation part of the process may use services H5 and Hg with the overall risk level 65 < 75. Therefore, during 
the execution we guard the second and the third instances to guarantee the low risk level values. There is no 
need to guard the first instance, since it satisfies the restriction in any case. Imagine, that during the execution 
H(, service has been selected. Before executing the next step the guard must check the resulting value, using 
the same rules as for the static analysis. In case H% is selected the execution is allowed (75 < 75). Otherwise, 
if H-j is chosen the restriction fails (78 > 75) and the execution is halted (or another action is performed, e.g., a 
report about the failure is sent to the customer and provider). 

□ 

6 Related work 

Outsourcing processing of sensitive data to external parties requires some assurances, that the data will be well 
protected while processed and transmitted. Unsurprisingly, several authors claimed that security requirements 
must be included into the agreement between service customer and service provider 1131 [Toll . Our work extends 
the existing state of the art with a unified approach for checking security properties and security metrics of 
complex business processes which appear as statements in such agreements. 
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Many authors proposed formal languages for specifying and verifying agreements, also called contracts, 
between a service provider and a customer. Padovani lf2TTl proposes a language for defining service contracts 
and presents a theory for the automatic generation of service orchestrators. Subcontract relations are used to 
find a matching between the contract offered by a service and the requirements of its clients. Similarly, Bravetti 
and Zavattaro [ 8 ] present a language for the specification of service contracts. Their contracts have a process 
algebra-based semantics and allow for the specification of composed services. Contract composition can be 
verified to guarantee that the interaction of a group of services does not violate the specifications. Even though 
these works do not focus on security analysis, their contracts can be adapted to model security requirements. 

Martinelli and Matteucci [17] presented a framework for the synthesis of a secure orchestrator, i.e., an 
agent which drives the interaction between two services guaranteeing that a certain security policy is respected. 
Although, the proposals described above use contracts for the specification and analysis of history-based ID 
service properties, none of them allows for the definition of security metrics and restrictions on them. 

In order to check whether a complex business process satisfies some quantitative requirements aggregation 
of security metric values for atomic services is required. For example, Cheng et. al. [ 10] aggregated downtime 
metric, considering business process like a simple set of activities, i.e., regardless the operational flow. 

In contrast, Jaeger et. al. lfT9l have shown that some metrics could be aggregated differently depending on 
the structural activity used for joining the atomic services. In this work all metrics were considered separately. 
Moreover, the author did not considered security metrics. Yu et. al. Il24ll23l applied the idea of Jeager at. al. for 
selection of the best process among several alternatives. The authors defined aggregation functions for several 
metrics and aimed at selection of the best alternative which satisfies the constraints specified in the agreement. 
First the authors defined a utility function and proposed to solve a 0- 1 multi-dimension multi-choice knapsack 
problem (MMKP) only for a sequential order |23l . Solutions for a general workflow were proposed later [24J. 

Massacci and Yautsiukhin [18 ] proposed a method and an algorithm for aggregation of security metrics. 
The authors also solved the problem of selection the best (i.e., more secure) alternative, though a wider range 
of metrics were considered (these metrics cannot be used in classical algorithms for finding the shortest path). 
The method was extended for checking several metrics at the same time using Pareto optimality strategy Ifl4l . 

In our work we do not have a goal to select the business process which has the best metric value. Moreover, 
we assume that some processes which do have a value worse than desired may still satisfy the policy if a more 
secure execution path is selected for a specific invocation. Therefore, our proposal allows making a decision at 
design time and supporting control at run-time. 

7 Conclusion 

In this paper we presented a novel approach for dealing with the analysis and verification of both security and 
metric requirements of web services. Our system is developed on existing solutions for modelling security and 
metric-based requirements. The result is a unified framework for (i) the definition and application of security 
and metric policies within service implementation, (ii) the automatic extraction of history expressions carrying 
metric annotations and (Hi) the computation (through an equational theory) of metric values which safely predict 
the expected behaviour of services. Our proposal requested a new type and effect system, extending existing 
approaches, to be defined. Interestingly, we found that adding metric annotations does not invalidate the type 
safety property, i.e., annotations are orthogonal to the history expressions. 

The present work is a first step toward a complete model for the specification and verification of quantitative 
and qualitative, non functional requirements for web services. Further effort is requested in order to generalise 
our approach. In particular, we aim at defining a procedure for generating orchestration plans starting from the 
history expressions produced by our type and effect system. Such method has been presented in [4] for metric- 
free history expressions and we believe that similar results can be extended to our proposal. Another limitation 
of the current model is our static description of metric value for the events. Even though we think that assigning 
metric values to events is a reasonable way to model the actual behaviour of services, it is not always correct to 
assume these values to keep unchanged in time. Indeed, many metrics aim at modelling dynamic evolution of 
some property, e.g., reputation or number of system failures, which we cannot model with our approach. 
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